目標ノードからの予測情報に基づくハンドオーバ

专利摘要:
無線リソース管理（ＲＲＭ）情報を収集し、ユーザ装置（ＵＥ）についてハンドオーバが開始されることになると判断し、そして、ハンドオーバが開始されることになるという判断に応じて、ＲＲＭ情報を含むハンドオーバリクエストメッセージを送信するためのソースノード（１２２−１）を、システム（１００）が備えてもよい。システムは、さらに、ソースノードからハンドオーバリクエストメッセージを受信し、ハンドオーバリクエストメッセージの受信に応じて、目標ノードについての現在のネットワーク情報を識別し、ＲＲＭ情報と識別された現在のネットワーク情報とに基づいてＵＥについてのハンドオーバフィードバック情報を生成し、そして、ハンドオーバレスポンスメッセージをソースノードへ送信するための目標ノード（１２２−２）を含むのだが、ハンドオーバレスポンスメッセージは、生成されたハンドオーバフィードバック情報を含み、生成されたハンドオーバフィードバック情報は、ハンドオーバに関する決定を行う際にソースノードを支援する。
公开号:JP2011511542A
申请号:JP2010544597
申请日:2008-07-09
公开日:2011-04-07
发明作者:エレナ ヴォルトリナ，；ガボール フォドール，
申请人:テレフオンアクチーボラゲット エル エム エリクソン（パブル）；
IPC主号:H04W36-26

专利说明:

[0001] 本書で記述する実施形態は、一般にワイヤレスネットワークに関し、詳細には、ワイヤレスネットワーク内の目標ノードからの予測情報に基づいてハンドオーバの決定を行うことに関する。]
背景技術

[0002] 通常、ハンドオーバでの許可制御は、ユーザ装置（ＵＥ）の無線ベアラのサービス品質（ＱｏＳ）要件と目標セルのリソース状況とに基づいて目標セルによって行われる。このために、セルラー標準は、無線ベアラ情報が１つのセルから他のセルへ伝達されることを可能にする、基地局間の、および／または、関連する無線ネットワーク制御装置間の信号メッセージを規定している。ＱｏＳ保証のない（すなわち、保証されたビットレート（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ（ＧＢＲ））のない）無線ベアラについては、目標セルは許可制御を行わない。実際、非ＧＢＲ無線ベアラは、常に、ハンドオーバの時点で目標セルによって許可され、その後は、ベストエフォートに基づいて（すなわち、無線、トランスポート、ハードウェア／ソフトウェア、および／または、その他のタイプのリソースを予約せずに）扱われる。]
[0003] 例えば、Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（Ｅ−ＵＴＲＡＮ）では、ハンドオーバの準備の間、進化型ノードＢ（ｅＮＢ）とも呼ばれるソース（ハンドオーバ元）基地局は、無線ベアラ固有の無線リソース管理（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ（ＲＲＭ））情報を目標基地局（ｅＮＢ）へＸ２インタフェースで伝達することができる。無線ベアラ固有のＲＲＭ情報には、特定のユーザ装置（ＵＥ）の過去および現在の無線リソース利用に関する情報が含まれてもよい。]
発明が解決しようとする課題

[0004] しかし、ターゲット（ハンドオーバ先）となる目標基地局は、新たに到着するＵＥの実際のリソース需要を考慮していないし、ベストエフォートサービスについてリソースを予約することもしていない。従って、この典型的ないわゆる「ベストエフォート」という枠組みは、知覚されるＱｏＳと提供される無線リソースとが、目標基地局にハンドオーバされるＵＥについて最大化されないという意味で、実際にはベストエフォートではない。これは、目標基地局が、ＵＥの無線ベアラに関連して利用可能な信号伝達された（現在標準化されたＱｏＳパラメータに限定されてもよい）ＱｏＳパラメータを使用するからである。]
[0005] 従って、ソース基地局が、特定のＵＥに関連する進行中のセッションについて適切なサービスレベルを提供できない目標セルにＵＥを方向付けることがある。例えば、ＵＥが非ＧＢＲ（ベストエフォート）サービスを利用している場合、豊富なリソースを持つ別の目標セルがＵＥを収容することができた場合でさえ、リソースが少ない目標セルがハンドオーバ用に選択されることがある。]
[0006] 本発明の目的は、上記の不利点の少なくとも一部を克服して、ハンドオーバ処理を向上させることである。]
課題を解決するための手段

[0007] 本書で記述する実施形態には、ハンドオーバの後でＵＥがソースノードで現在受けているのと同じサービス品質をＵＥが目標ノードで受ける可能性を予測するシステムおよび／または方法が含まれてもよい。ソースノードは、関連する無線ベアラパラメータよりきめ細かい情報を提供する、個別のＵＥについての現在のアクティビティおよびリソース利用の情報（ＵＥ固有ＲＲＭ情報と呼ばれる）を収集してもよい。この利点は、最大（またはピーク）ビットレートがＧＢＲよりも大きい（ＭＢＲ＞ＧＢＲ）非ＧＢＲベアラとＧＢＲベアラとの両方に適用可能であってもよい。後者の場合、実際にサポートされるビットレートに関してソースセルと目標セルとの間に大きな差があってもよい（例えば、ソースセルがＭＢＲに近く、他方、目標セルがＧＢＲに近くてもよい）。]
[0008] 目標ノードは、無線ベアラ固有のＲＲＭ情報だけから目標ノードが得ることができる情報よりも、ＵＥの実際のリソース要件に関するもっと正確な情報ともっときめ細かい情報とを有する可能性がある。目標ノードは、この情報を用いて、ハンドオーバの後で新たなセル（すなわち、目標ノードによって提供されるセル）で同じＱｏＳをＵＥが受ける可能性を示す予測をソースノードに提供することができる。また、目標ノードは、ハンドオーバの準備が失敗した場合に備えて、ハンドオーバフィードバック情報を提供してもよい。従って、ソースノードのハンドオーバの決定が、ハンドオーバの時点でもう使われていない可能性があった背景負荷情報によってだけでなく、目標ノードのリソース状況についての最新情報によっても助けられてよい。]
[0009] 一実施形態では、ソースノードは、ベストエフォート（非ＧＢＲ）のアプリケーションまたは弾力的な（ＭＢＲ＞ＧＢＲ）アプリケーションを実行しているＵＥに積極的に警告を送信することができる。警告は、目標ノードは最小ビットレートおよびＱｏＳに責任を持つことはできるが、知覚されるＱｏＳの劣化がハンドオーバの実行後に発生しそうであることを示してもよい。例えば、ＵＥは、アプリケーションレイヤに対するレイヤ間信号の中でこの情報を用いることもできる。結果として、ＵＥは、ハンドオーバの前の所定の時期に再構成すること（そして、新たなリソース状況に適合すること）によって、リソースの問題を持つセルの中でサービスを受け続ける可能性が高まってもよい。]
[0010] 例示的な一実施形態では、無線リソース管理（ＲＲＭ）情報を収集し、ユーザ装置（ＵＥ）についてハンドオーバが開始されることになると判断し、そして、ハンドオーバが開始されることになるという判断に応じて、ＲＲＭ情報を含むハンドオーバリクエストメッセージを送信するためのソースノードを、本書で記述するシステムが含んでもよい。システムはさらに、ソースノードからハンドオーバリクエストメッセージを受信し、ハンドオーバリクエストメッセージの受信に応じて、目標ノードの現在のネットワーク情報を識別し、ＲＲＭ情報と識別された現在のネットワーク情報とに基づいてＵＥについてのハンドオーバフィードバック情報を生成し、そして、ハンドオーバレスポンスメッセージをソースノードへ送信するための目標ノードを含んでもよい。前記ハンドオーバレスポンスメッセージは、生成されたハンドオーバフィードバック情報を含んでもよい。生成されたハンドオーバフィードバック情報は、ハンドオーバに関する決定を行う際にソースノードを支援してもよい。]
図面の簡単な説明

[0011] 本書で記述するシステムおよび方法が実装されうる例示的なネットワーク１００の図である。
図１のＵＥの例示的な実装の図である。
図２のＵＥの例示的なコンポーネントの図である。
図１の進化型ノードＢ（ｅＮＢ）の例示的なコンポーネントの図である。
図１のｅＮＢに関連しうる例示的なコンピュータ可読媒体の図である。
図１のＭｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ（ＭＭＥ）／Ｇａｔｅｗａｙ（ＧＷ）の例示的なコンポーネントの図である。
ハンドオーバを行う例示的なプロセスのフローチャートである。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
図７に関する上記の処理の例の図である。
ハンドオーバを行う別の例示的なプロセスのフローチャートである。] 図１ 図２ 図７
実施例

[0012] 下記の詳細記述では、添付の図面を参照する。異なる図面における同じ参照番号は、同じかまたは類似する要素を特定することがある。また、下記の詳細記述は、本発明を限定しない。]
[0013] 本書で記述する諸実施形態は、ワイヤレスネットワークにおけるハンドオーバを向上させる。一実施形態では、ＵＥについてのハンドオーバが開始されることになると判断することに応じて、ソースノードが、ＲＲＭ情報を目標ノードに転送してもよい。目標ノードは、目標ノードに関連する現在のネットワーク情報と共にＲＲＭ情報を用いて、ＵＥについてのハンドオーバフィードバック情報を生成してもよい。目標ノードは、ハンドオーバフィードバック情報をソースノードに転送してもよい。ソースノードは、そのハンドオーバフィードバック情報を、ＵＥで現在実行されているサービスが、ハンドオーバの後、新たなセル（すなわち、目標ノードによってサポートされるセル）でも同レベルのＱｏＳで維持されることができる可能性の予測として用いてもよい。]
[0014] 図１は、本書で記述するシステムおよび方法が実装されうる例示的なネットワーク１００の図である。図示するように、ネットワーク１００は、ユーザ装置（ＵＥ）１１０と、Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（Ｅ−ＵＴＲＡＮ）１２０と、Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ（ＥＰＣ）１３０とを含んでもよい。図１に示すコンポーネントの数は、話を簡単にするために提供されている。実際には、ネットワーク１００が、図１に示すもの以外に追加のコンポーネント、および／または、別のコンポーネントを含んでもよい。] 図１
[0015] ＵＥ１１０は、Ｅ−ＵＴＲＡＮ１２０との間でトラヒック（例えば音声および／またはデータ）を送受信することができる１つ以上のデバイスを含んでもよい。一実施形態では、ＵＥ１１０は、例えば、ワイヤレス電話、携帯情報端末（ＰＤＡ）、ラップトップ等を含んでもよい。]
[0016] Ｅ−ＵＴＲＡＮ１２０は、ＵＥ１１０が通信できる、例えば、第三世代パートナシッププロジェクト（３ＧＰＰ）技術仕様（ＴＳ）３６．３００で定義されるようなネットワークを含んでもよい。図示するように、Ｅ−ＵＴＲＡＮ１２０は、（集合的に「ｅＮＢ １２２」と呼ばれる）進化型ノードＢ（ｅＮＢ）のグループ１２２−１乃至１２２−２を含んでもよい。話を簡単にするために、２つのｅＮＢ １２２を示した。実際には、もっと多くのｅＮＢが存在してもよい。]
[0017] （基地局とも呼ばれる）ｅＮＢ １２２は、ＵＥ１１０から無線インタフェースを介してトラヒック（例えば音声および／またはデータ）を受信して、無線インタフェースを介してＵＥ１１０にトラヒック（例えば音声および／またはデータ）を送信するような１つ以上のデバイスを含んでもよい。一実施形態では、ｅＮＢ １２２−１は、Ｘ２インタフェースを介してｅＮＢ １２２−２と通信してもよい。]
[0018] ＥＰＣ１３０は、Ｅ−ＵＴＲＡＮ１２０からトラヒック（例えばパケット交換トラヒック）を受信して、前記トラヒックを別のネットワークに、例えばインターネットのようなＰｕｂｌｉｃ Ｄａｔａ Ｎｅｔｗｏｒｋ（ＰＤＮ）に転送し、そして、その他方のネットワークからトラヒックを受信して、前記トラヒックをＥ−ＵＴＲＡＮ１２０に転送するようなネットワークを含んでもよい。図示するように、ＥＰＣ１３０は、 Ｅｎｔｉｔｉｅｓ（ＭＭＥ）／Ｇａｔｅｗａｙ（ＧＷ）のグループ１３２−１乃至１３２−２（集合的に「ＭＭＥ／ＧＷ １３２」と呼ばれる）を含んでもよい。話を簡単にするために、２つのＭＭＥ／ＧＷ １３２を示した。実際には、もっと多くのＭＭＥ／ＧＷが存在してもよい。]
[0019] 各ＭＭＥ／ＧＷ１３２−１乃至１３２−２は、１つのＭＭＥと１つのＧＷとを含んでもよい。ＭＭＥは、ＵＥ１１０の移動性を管理する１つ以上のデバイスを含んでもよい。ＭＭＥは、さらに、認証および許可と、アイドルモードのＵＥの追跡および到達可能性交渉およびセキュリティ交渉と、Ｎｅｔｗｏｒｋ−Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｐｅｃｉｆｉｃ（ＮＡＳ）信号とを行う１つ以上のデバイスを含んでもよい。ＧＷは、ｅＮＢ１２２からの／へのトラヒックを受信／転送する１つ以上のデバイスを含んでもよい。ＧＷは、さらに、外部のＰＤＮへのインタフェースとして動作する１つ以上のデバイスを含んでもよい。ＭＭＥ／ＧＷ１３２−１およびＭＭＥ／ＧＷ１３２−２は、Ｓ１インタフェースを介してｅＮＢ１２２−１およびｅＮＢ１２２−２と通信してもよい。]
[0020] 図２は、ＵＥ１１０の例示的な実装の図である。図２に示す例では、ＵＥ１１０は、携帯電話として実装される。ＵＥ１１０は、マイクロフォン２１０と、スピーカ２２０と、入力要素のグループ２３０と、ディスプレイ２４０とを含んでもよい。] 図２
[0021] マイクロフォン２１０が、ＵＥ１１０のユーザからの可聴情報を受信してもよい。スピーカ２２０が、ＵＥ１１０のユーザに可聴情報を提供してもよい。入力要素２３０は、制御ボタンおよび／またはキーパッドを含んでもよい。制御ボタンは、ＵＥ１１０に１つ以上の操作を行わせるためにユーザがＵＥ１１０と対話することを可能にしてもよい。例えば、制御ボタンが、ＵＥ１１０に情報を送信させるために用いられてもよい。キーパッドは、標準の電話キーパッドを含んでもよい。ディスプレイ２４０は、視覚情報をユーザに提供してもよい。例えば、ディスプレイ２４０が、ＵＥ１１０へのテキスト入力と、および／または、他のデバイス、例えばｅＮＢ１２２−１から受信したテキストおよび／または画像と、および／または、着信または発信される呼に関する情報と、または、テキストメッセージと、メディアと、ゲームと、電話帳と、アドレス帳と、現在時刻等を、表示してもよい。]
[0022] 図２は、ＵＥ１１０の例示的なコンポーネントを示すが、他の実装では、図２に示すものと較べて、ＵＥ１１０のコンポーネントがより少なくてもよいし、異なってもよいし、追加されてもよい。さらに別の実装では、ＵＥ１１０の１つ以上のコンポーネントが、ＵＥ１１０の１つ以上の他のコンポーネントによって行われると記述したタスクを行ってもよい。] 図２
[0023] 図３は、図２のＵＥ１１０の例示的なコンポーネントの図である。図示するように、ＵＥ１１０は、アンテナ３１０と、通信部３２０と、処理ロジック３３０と、メモリ３４０と、入力デバイス３５０と、出力デバイス３６０と、バス３７０とを含んでもよい。] 図２ 図３
[0024] アンテナ３１０は、無線で無線周波数（ＲＦ）信号を送信および／または受信するための１つ以上のアンテナを含んでもよい。アンテナ３１０は、例えば、ＲＦ信号を通信部３２０から受信してＲＦ信号を無線でｅＮＢ１２２−１へ送信し、ＲＦ信号を無線でｅＮＢ１２２−１から受信してＲＦ信号を通信部３２０に提供してもよい。]
[0025] 通信部３２０は、例えば、処理ロジック３３０からのベースバンド信号をＲＦ信号に変換しうる送信器、および／または、ＲＦ信号をベースバンド信号に変換しうる受信器を含んでもよい。あるいは、通信部３２０は、送信器と受信器との両方の機能を行う通信部を含んでもよい。通信部３２０は、ＲＦ信号の送信および／または受信のためにアンテナ３１０に接続してもよい。]
[0026] 処理ロジック３３０は、プロセッサと、マイクロプロセッサと、特定用途向け集積回路（ＡＳＩＣ）と、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）と、その他を含んでもよい。処理ロジック３３０は、ＵＥ１１０とそのコンポーネントの操作を制御してもよい。]
[0027] メモリ３４０は、処理ロジック３３０によって使用されうるデータと命令とを記憶するために、ランダム・アクセス・メモリ（ＲＡＭ）と、リード・オンリー・メモリ（ＲＯＭ）と、および／または、別のタイプのメモリとを含んでもよい。入力デバイス３５０は、ＵＥ１１０にデータを入力するためのメカニズムを含んでもよい。例えば、入力デバイス３５０は、例えばマイクロフォン２１０と、入力要素２３０と、ディスプレイ２４０とのような入力メカニズムを含んでもよい。出力デバイス３６０は、音声と、動画と、および／またはハードコピー形式としてデータを出力するためのメカニズムを含んでもよい。例えば、出力デバイス３６０は、スピーカ２４０と、ディスプレイ２４０と、その他を含んでもよい。バス３７０は、ＵＥ１１０の各種のコンポーネントを相互接続して、それらのコンポーネントが相互に通信することを可能にしてもよい。]
[0028] 図３は、ＵＥ１１０の例示的なコンポーネントを示しているが、他の実装においては、ＵＥ１１０は、図３に示すものと較べて、コンポーネットがより少なくてもよいし、異なってもよいし、追加されてもよい。さらに別の実装では、ＵＥ１１０の１つ以上のコンポーネントが、ＵＥ１１０の１つ以上の他のコンポーネントによって行われると記述したタスクを行ってもよい。] 図３
[0029] 図４は、ｅＮＢ１２２−１の例示的なコンポーネントの図である。ｅＮＢ１２２−２も、同様に構成されてもよい。図示するように、ｅＮＢ１２２−１は、アンテナ４１０と、通信部４２０と、処理システム４３０と、インタフェース４４０とを含んでもよい。] 図４
[0030] アンテナ４１０は、１つ以上の指向性アンテナおよび／または全方向性アンテナを含んでもよい。通信部４２０は、アンテナ４１０に関連付けられてもよく、アンテナ４１０を介して、例えばネットワーク１００のようなネットワークにおいてシンボルのシーケンスを送信および／または受信するための通信部回路構成を含んでもよい。]
[0031] 処理システム４３０は、ｅＮＢ１２２−１の操作を制御してもよい。また、処理システム４３０は、通信部４２０とインタフェース４４０とを介して受信した情報を処理してもよい。図示するように、処理システム４３０は、処理ロジック４３２とメモリ４３４とを含んでもよい。理解されるであろうが、処理システム４３０は、図４に示すものと較べて、追加のコンポーネントおよび／または異なるコンポーネントを含んでもよい。] 図４
[0032] 処理ロジック４３２は、プロセッサと、マイクロプロセッサと、ＡＳＩＣと、ＦＰＧＡと、その他を含んでもよい。処理ロジック４３２は、通信部４２０とインタフェース４４０とを介して受信した情報を処理してもよい。処理には、例えば、データ変換と、前方誤り訂正（ＦＥＣ）と、レート適応と、広帯域符号分割多元接続（ＷＣＤＭＡ）拡散／不拡散と、四相位相変調（ＱＰＳＫ）と、その他が含まれてもよい。加えて、処理ロジック４３２は、制御メッセージおよび／またはデータメッセージを生成して、これらの制御メッセージおよび／またはデータメッセージが、通信部４２０および／またはインタフェース４４０を介して送信されるようにしてもよい。また、処理ロジック４３２は、通信部４２０および／またはインタフェース４４０から受信した制御メッセージおよび／またはデータメッセージを処理してもよい。メモリ４３４は、処理ロジック４３２によって使用されうるデータと命令とを記憶するために、ＲＡＭと、ＲＯＭと、および／または、別のタイプのメモリを含んでもよい。]
[0033] インタフェース４４０は、ｅＮＢ１２２−１が、有線接続および／またはワイヤレス接続によって他のデバイスへデータを送信して他のデバイスからデータを受信することを可能にするような１つ以上のラインカードを含んでもよい。図示するように、インタフェース４４０は、ｅＮＢ１２２−１が、例えばＭＭＥ／ＧＷ１３２−１および／または１３２−２のようなＭＭＥ／ＧＷと通信することを可能にするようなＳ１インタフェースと、ｅＮＢ１２２−１が、例えばｅＮＢ１２２−２のような別のｅＮＢと通信することを可能にするようなＸ２インタフェースとを含んでもよい。]
[0034] ｅＮＢ１２２−１は、例えばメモリ４３４のようなコンピュータ可読媒体に含まれるソフトウェア命令を処理ロジック４３２が実行するのに応じて、一定の操作を行ってもよい。コンピュータ可読媒体とは、１つ以上の物理的および／または論理的メモリデバイスとして定義されてもよい。ソフトウェア命令は、別のコンピュータ可読媒体から、または、別のデバイスから、インタフェース４４０を介してメモリ４３４に読み込まれてもよい。メモリ４３４に含まれるソフトウェア命令が、本書で記述するプロセスを処理ロジック４３２に行わせてもよい。あるいは、本書で記述するプロセスを実装するため、ソフトウェア命令の代わりに、または、ソフトウェア命令と組み合わせて、ハードウェア回路構成が用いられてもよい。従って、本書で記述する実施形態は、ハードウェア回路構成とソフトウェアとのいずれかの特定の組み合わせに限定されない。]
[0035] 図４は、ｅＮＢ１２２−１の例示的なコンポーネントを示すが、他の実装では、図４に示すものと較べて、ｅＮＢ１２２−１のコンポーネントがより少なくてもよいし、異なってもよいし、追加されてもよい。さらに別の実装では、ｅＮＢ１２２−１の１つ以上のコンポーネントが、ｅＮＢ１２２−１の１つ以上の他のコンポーネントによって行われると記述したタスクを行ってもよい。] 図４
[0036] 図５は、ｅＮＢ１２２−１に関連付けられてもよい例示的なコンピュータ可読媒体５００および５３０を示す図である。理解されるであろうが、同様のコンピュータ可読媒体がｅＮＢ１２２−２に関連付けられてもよい。２つのコンピュータ可読媒体について以下に記述するけれども、理解されるであろうが、コンピュータ可読媒体５００および５３０は、ｅＮＢ１２２−１でローカルに（例えばメモリ４３４の中に）記憶される追加のコンピュータ可読媒体、または、１つ以上の異なる位置、そして場合によってはリモートな位置に記憶される追加のコンピュータ可読媒体を含んでもよい。] 図５
[0037] 図示するように、コンピュータ可読媒体５００は、下記の例示的なフィールド、すなわち、ＵＥ識別子フィールド５１０と、Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ（ＲＲＭ） Ｉｎｆｏｒｍａｔｉｏｎ（ＩＮＦＯ）フィールド５２０との中にエントリのグループを維持してもよい。コンピュータ可読媒体５００は、図５に示すもの以外に、追加の情報、または、別の情報を維持してもよい。] 図５
[0038] ＵＥ識別子フィールド５１０は、ｅＮＢ１２２−１に関連するＵＥ、例えばＵＥ１１０を識別する一連の文字列を記憶してもよい。一実施形態では、一連の文字列は、そのＵＥについて一意であってもよい。例えば、文字列は、ネットワークアドレスに対応してもよい。ＲＲＭＩＮＦＯフィールド５２０は、フィールド５１０で識別されたＵＥについてｅＮＢ１２２−１によって取得されたＲＲＭ情報を記憶してもよい。一実施形態では、ＲＲＭ情報は、特定のＵＥの過去および／または現在の無線リソース利用に関する情報を含んでもよい。例えば、ＲＲＭ情報は、ＵＥの定期的なアップリンク／ダウンリンクのトラヒックと、受信／送信電力レベルと、時間軸および／または周波数軸における用いられたリソースブロックと、適用された間欠受信／送信（ＤＲＸ）設定と、用いられた無線リソースと、知覚されたＵＥのサービス品質とに関する情報、および／または、ＵＥについてハンドオーバ予測を判断する際に目標ｅＮＢにとって有用でありうるような他のタイプの情報を含んでもよい。]
[0039] コンピュータ可読媒体５３０は、下記の例示的なフィールド、すなわち、Ｒａｄｉｏ Ｂｅａｒｅｒ（ＲＢ）識別子フィールド５４０と、ＲＲＭＩＮＦＯフィールド５５０との中にエントリのグループを維持してもよい。コンピュータ可読媒体５３０は、図５に示すもの以外に、追加の情報、または、別の情報を維持してもよい。] 図５
[0040] ＲＢ識別子フィールド５４０は、ｅＮＢ１２２−１に関連する無線ベアラを識別する一連の文字列を記憶してもよい。一実施形態では、一連の文字列は、ｅＮＢ１２２−１に関するその無線ベアラについて一意であってもよい。ＲＲＭＩＮＦＯフィールド５５０は、フィールド５１０で識別された無線ベアラについてｅＮＢ１２２−１によって取得されたＲＲＭ情報を記憶してもよい。一実施形態では、ＲＲＭ情報は、アクティビティレベルと、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ（ＴＴＩ）毎の用いられた無線リソースブロックと、リソースブロック毎の用いられた電力レベルとに関する情報、および／または、ＵＥについてハンドオーバ予測を判断する際に目標ｅＮＢにとって有用でありうるような他のタイプの情報を含んでもよい。]
[0041] 図６は、ＭＭＥ／ＧＷ１３２−１の例示的なコンポーネントの図である。ＭＭＥ／ＧＷ１３２−２が、同様に構成されてもよい。図示するように、ＭＭＥ／ＧＷ１３２−１は、処理システム６１０とインタフェース６２０とを含んでもよい。] 図６
[0042] 処理システム６１０は、ＭＭＥ／ＧＷ１３２−１の操作を制御してもよい。また、処理システム６１０は、インタフェース６２０を介して受信した情報を処理してもよい。図示するように、処理システム６１０は、処理ロジック６１２とメモリ６１４とを含んでもよい。理解されるであろうが、処理システム６１０は、図６に示すもの以外に追加のコンポーネント、および／または、別のコンポーネントを含んでもよい。] 図６
[0043] 処理ロジック６１２は、プロセッサと、マイクロプロセッサと、ＡＳＩＣと、ＦＰＧＡと、その他を含んでもよい。処理ロジック６１２は、インタフェース６２０を介して受信した情報を処理してもよい。加えて、処理ロジック６１２は、制御メッセージおよび／またはデータメッセージを生成して、これらの制御メッセージおよび／またはデータメッセージが、インタフェース６２０を介して送信されるようにしてもよい。また、処理ロジック６１２は、インタフェース６２０から受信した制御メッセージおよび／またはデータメッセージを処理してもよい。メモリ６１４は、処理ロジック６１２によって使用されうるデータと命令とを記憶するために、ＲＡＭと、ＲＯＭと、および／または、別のタイプのメモリを含んでもよい。]
[0044] インタフェース６２０は、ＭＭＥ／ＧＷ１３２−１が、有線接続および／またはワイヤレス接続によって他のデバイスへデータを送信して他のデバイスからデータを受信することを可能にするような１つ以上のラインカードを含んでもよい。図示するように、インタフェース６２０は、ＭＭＥ／ＧＷ１３２−１が、例えばｅＮＢ１２２−１およびｅＮＢ１２２−２のようなｅＮＢと通信することを可能にするようなＳ１インタフェース６２２を含んでもよい。理解されるであろうが、インタフェース６２０は、図６に示すもの以外に、追加のインタフェースを含んでもよい。例えば、インタフェース６２０は、別のネットワーク、例えばＰＤＮと通信するためのインタフェースを含んでもよい。] 図６
[0045] ＭＭＥ／ＧＷ１３２−１は、例えばメモリ６１４のようなコンピュータ可読媒体に含まれるソフトウェア命令を処理ロジック６１２が実行するのに応じて、一定の操作を行ってもよい。ソフトウェア命令は、別のコンピュータ可読媒体から、または、別のデバイスから、インタフェース６２０を介してメモリ６１４に読み込まれてもよい。メモリ６１４に含まれるソフトウェア命令が、本書で記述するプロセスを処理ロジック６１２に行わせてもよい。あるいは、本書で記述するプロセスを実装するため、ソフトウェア命令の代わりに、または、ソフトウェア命令と組み合わせて、ハードウェア回路構成が用いられてもよい。従って、本書で記述する実施形態は、ハードウェア回路構成とソフトウェアとのいずれかの特定の組み合わせに限定されない。]
[0046] 図６は、ＭＭＥ／ＧＷ１３２−１の例示的なコンポーネントを示すが、他の実装では、図６に示すものと較べて、ＭＭＥ／ＧＷ１３２−１のコンポーネントがより少なくてもよいし、異なってもよいし、追加されてもよい。さらに別の実装では、ＭＭＥ／ＧＷ１３２−１の１つ以上のコンポーネントが、ＭＭＥ／ＧＷ１３２−１の１つ以上の他のコンポーネントによって行われると記述したタスクを行ってもよい。] 図６
[0047] 図７は、ハンドオーバを行うための例示的なプロセスのフローチャートである。一実施形態では、図７に記述する処理が、（例えば、１つ以上の保証されたビットレートのない（ｎｏｎ−Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ（非ＧＢＲ））無線ベアラか、または、サポートされる最大ビットレート（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ（ＭＢＲ））が保証されたビットレートを上回るような１つ以上のＧＢＲ無線ベアラを介して、ＵＥ１１０にサービス提供するソースｅＮＢとしての）ｅＮＢ１２２−１と、（例えば目標ｅＮＢとしての）ｅＮＢ１２２−２とによって行われてもよい。別の実施形態では、以下に記述する例示的なプロセスの一部または全部が、ｅＮＢ１２２を含むかまたはｅＮＢ１２２を除く、別のデバイスまたはデバイスの組み合わせによって行われてもよい。] 図７
[0048] 例示的なプロセスは、ソースｅＮＢ１２２−１がＲＲＭ情報（ブロック７０５）を収集することによって開始されてもよい。一実施形態では、ソースｅＮＢ１２２−１は、ＵＥ１１０に固有のＲＲＭ情報と、ソースｅＮＢ１２２−１に関連する無線ベアラに固有のＲＲＭ情報を収集してもよい。例えば、ソースｅＮＢ１２２−１は、ソースｅＮＢ１２２−１に関連するセルの中にＵＥ１１０が留まっている間、ＵＥ１１０についてのＲＲＭ情報を収集してもよい。ＵＥ固有のＲＲＭ情報は、例えば、ＵＥ１１０の過去および／または現在の無線リソースの利用を含んでもよい。例えば、ＲＲＭ情報は、ＵＥ１１０の定期的なアップリンク／ダウンリンクのトラヒックと、受信／送信電力レベルと、時間軸および／または周波数軸における用いられたリソースブロックと、適用されたＤＲＸ設定と、用いられた無線リソースと、知覚されたＵＥ１１０のサービス品質とに関する情報、および／または、ＵＥ１１０についてハンドオーバ予測を判断する際に目標ｅＮＢにとって有用でありうるような他のタイプの情報を含んでもよい。無線ベアラ固有のＲＲＭ情報は、例えば、ＵＥ１１０に関連する無線ベアラのアクティビティレベルと、無線ベアラについてのＴＴＩ毎の用いられた無線リソースブロックと、リソースブロック毎の用いられた電力レベルとに関する情報、および／または、ＵＥ１１０についてハンドオーバ予測を判断する際に目標ｅＮＢにとって有用でありうるような他のタイプの情報を含んでもよい。ソースｅＮＢ１２２−１は、ＵＥ固有のＲＲＭ情報をコンピュータ可読媒体、例えばコンピュータ可読媒体５００の中に記憶してもよい。ソースｅＮＢ１２２−１は、さらに、無線ベアラ固有のＲＲＭ情報をコンピュータ可読媒体、例えばコンピュータ可読媒体５３０の中に記憶してもよい。]
[0049] ソースｅＮＢ１２２−１が、ＵＥ１１０についてハンドオーバが開始されるべきだと判断してもよい（ブロック７１０）。一実施形態では、ソースｅＮＢ１２２−１が、測定報告に基づいてハンドオーバが開始されるべきだと判断してもよい。例えば、ソースｅＮＢ１２２−１が、ＵＥ１１０に、測定を行って、測定報告を生成し、測定報告をソースｅＮＢ１２２−１に送信するよう、命令してもよい。他の実施形態では、ソースｅＮＢ１２２−１が、他の情報に基づいてＵＥ１１０についてハンドオーバが開始されるべきだと判断してもよい。]
[0050] ＵＥ１１０についてハンドオーバが開始されるべきだと判断することに応じて、ソースｅＮＢ１２２−１が、ハンドオーバリクエストメッセージを作成してもよい（ブロック７１５）。ハンドオーバリクエストメッセージは、ＵＥ１１０に関するＲＲＭ情報（例えば、ＵＥ固有のＲＲＭ情報および／または無線ベアラ固有のＲＲＭ情報）を含んでもよい。一実施形態では、ハンドオーバリクエストメッセージは、３ＧＰＰ ＴＳ３６．４２３に定義されたＨＡＮＤＯＶＥＲＲＥＱＵＥＳＴメッセージを含んでもよい。ＲＲＭ情報は、例えば、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴメッセージのＵＥ Ｈｉｓｔｏｒｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ（ＩＥ）の中に提供されてもよい。一旦作成されると、ソースｅＮＢ１２２−１は、ハンドオーバリクエストメッセージを目標ｅＮＢ１２２−２へ転送してもよい（ブロック７１５）。ソースｅＮＢ１２２−１は、ハンドオーバリクエストメッセージをＸ２インタフェースで転送してもよい。]
[0051] 目標ｅＮＢ１２２−２は、ハンドオーバリクエストを受信してもよく（ブロック７２０）、そして、それに応じて、目標ｅＮＢ１２２−２についての現在のネットワーク情報を識別してもよい（ブロック７２５）。一実施形態では、現在のネットワーク情報は、目標ｅＮＢ１２２−２の現在のリソース状況、例えば、目標ｅＮＢ１２２−２の現在の容量状況および／または現在の負荷状況に関する情報を含んでもよい。]
[0052] 目標ｅＮＢ１２２−２は、ハンドオーバリクエストで受信されたＲＲＭ情報に基づいて、かつ、目標ｅＮＢ１２２−２についての識別された現在のネットワーク情報に基づいて、ＵＥ１１０についてのハンドオーバフィードバック情報を生成してもよい（ブロック７３０）。ハンドオーバフィードバック情報は、例えば、受信されたＲＲＭ情報と目標ｅＮＢ１２２−２についての識別された現在のネットワーク情報とに基づいて、目標ｅＮＢ１２２−２がソースｅＮＢ１２２−１と同じアクティビティレベルをＵＥ１１０についてサポートできないことがあるというインジケーション（指標）を含んでもよい。一実施形態では、指標は、劣化レベルとして提供されてもよい。例えば、「１」は、性能の劣化のリスクが小さいことを示してもよく、「２」は、性能の劣化のリスクが中程度であることを示してもよく、「３」は、性能の劣化のリスクが大きいことを示してもよく、その場合、ソースｅＮＢ１２２−１は、できればＵＥ１１０のアクティビティレベルを修正するように強く忠告される。加えて、ハンドオーバフィードバック情報は、ソースｅＮＢ１２２−１によって提供されるものより少ない無線リソースを受信してもよい無線ベアラを識別してもよい。また、ハンドオーバフィードバック情報は、目標ｅＮＢ１２２−２が（例えば、サポートされるパケット遅延、スループット等に関して）サポートしうるアクティビティを示してもよい。]
[0053] 目標ｅＮＢ１２２−２が、ハンドオーバレスポンスメッセージを作成してもよい（ブロック７３５）。ハンドオーバレスポンスメッセージは、ハンドオーバフィードバック情報を含んでもよい。一実施形態では、ハンドオーバレスポンスメッセージは、３ＧＰＰ ＴＳ３６．４２３に定義されたＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴＡＣＫＮＯＷＬＥＤＧＥメッセージとして作成されてもよい。ただし、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージの形式は、目標ｅＮＢ１２２−２によって生成されたハンドオーバフィードバック情報を含むように修正されてもよい。例えば、Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ（ＳＡＥ）Ｂｅａｒｅｒｓ Ａｄｍｉｔｔｅｄ ＬｉｓｔＩＥの中の各ベアラについて、目標ｅＮＢ１２２−２は、ハンドオーバフィードバック情報を含むＨａｎｄｏｖｅｒ（ＨＯ）Ｅｖａｌｕａｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ Ｄａｔａ ＩＥを含んでもよい。あるいは、ハンドオーバフィードバック情報は、Ｔａｒｇｅｔ−ｅＮＢ−ｔｏ−Ｓｏｕｒｃｅ−ｅＮＢ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ ＩＥの中に含まれてもよい。（ＨＯ Ｅｖａｌｕａｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ Ｄａｔａ ＩＥをＳＡＥ Ｂｅａｒｅｒｓ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ ＩＥの一部として含む）修正されたＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージと、ＨＯ Ｅｖａｌｕａｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ Ｄａｔａ ＩＥとの例示的な形式を、以下の表１と表２とに、それぞれ示す。]
[0054] ]
[0055] ]
[0056] ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴＡＣＫＮＯＷＬＥＤＧＥメッセージを作成する代わりに、目標ｅＮＢ１２２−２が、ハンドオーバリクエストメッセージを受信するのに応じて別のタイプのメッセージを作成してもよい。例えば、目標ｅＮＢ１２２−２が、３ＧＰＰ ＴＳ３６．３３１によって定義されたＭｏｂｉｌｉｔｙ制御情報を含むハンドオーバレスポンスメッセージを作成してもよい。（ハンドオーバフィードバック情報を含む）Ｍｏｂｉｌｉｔｙ制御情報の例示的な形式を以下の表３に示す。]
[0057] ]
[0058] 目標ｅＮＢ１２２−２は、ハンドオーバレスポンスメッセージをソースｅＮＢ１２２−１へ転送してもよい（ブロック７３５）。目標ｅＮＢ１２２−２は、ハンドオーバレスポンスメッセージをＸ２インタフェースで転送してもよい。]
[0059] ソースｅＮＢ１２２−１が、ハンドオーバレスポンスメッセージを受信してもよい（ブロック７４０）。ソースｅＮＢ１２２−１は、ハンドオーバフィードバック情報を識別するためにハンドオーバレスポンスメッセージを解析してもよい。ソースｅＮＢ１２２−１は、受信されたハンドオーバフィードバック情報に基づいて複数の動作を行ってもよい。例えば、ソースｅＮＢ１２２−１は、目標ｅＮＢ１２２−２から受信したハンドオーバフィードバック情報に基づいて、ハンドオーバの準備が整っている別の目標ｅＮＢの方が、ハンドオーバに適していると判断してもよい（ブロック７４５）。結果として、ソースｅＮＢ１２２−１は、別の、より適した方の目標ｅＮＢにＵＥ１１０をハンドオーバしてもよい。]
[0060] 別の例として、ソースｅＮＢ１２２−１は、ＵＥ１１０がソースｅＮＢ１２２−１と通信するためのスケジューリングストラテジーを、目標ｅＮＢ１２２−２のリソース容量にＵＥ１１０を適合させるように修正してもよい（ブロック７５０）。その後、ＵＥ１１０は、修正されたスケジューリングストラテジーに従ってソースｅＮＢ１２２−１と通信してもよい。目標ｅＮＢ１２２−２へのハンドオーバが行われる場合、ＵＥ１１０に関連するユーザは、性能の劣化に気づかなくてもよい。]
[0061] 別の例として、ソースｅＮＢ１２２−１が、ＵＥ１１０に１つ以上の進行中のサービスを再構成させるために、コマンドをＵＥ１１０に送信してもよい（ブロック７５５）。例えば、ユーザデバイス１１０が現在オンラインゲームをするのに使用されていると想定する。ソースｅＮＢ１２２−１は、（例えばリソースの消費を減らす目的で）ＵＥ１１０に１つ以上のゲームの設定を再構成させるために、コマンドをＵＥ１１０に送信してもよい。従って、ＵＥ１１０は、（例えばリソースの消費を減らす目的で）ＵＥ１１０で実行中のアプリケーションの１つ以上の特性を再構成するために、ＵＥ１１０のプロトコルスタックの低位レイヤ（例えば、無線通信を扱うプロトコルスタックの部分）がプロトコルスタックの高位レイヤ（例えば非アクセス層／サービスレイヤ）と対話するような動作を行ってもよい。目標ｅＮＢ１２２−２へのハンドオーバが行われる場合、ＵＥ１１０に関連するユーザは、性能の劣化に気づかなくてもよい。]
[0062] 別の例として、ソースｅＮＢ１２２−１が、劣化警告をＵＥ１１０へ送信してもよい（ブロック７６０）。例えば、サービスの劣化が近づいていることをユーザに警告するために、ソースｅＮＢ１２２−１がメッセージをＵＥ１１０上に表示させてもよい。メッセージはさらに、ユーザが体験するであろう性能の劣化の量を減らす目的でユーザが行いうる１つ以上の動作、例えばＵＥ１１０で現在実行中のアプリケーションの１つ以上の特性を変更すること、を含んでもよい。]
[0063] 理解されるであろうが、ソースｅＮＢ１２２−１が、上記の動作を組み合わせて行ってもよい。また、ソースｅＮＢ１２２−１が、上記の動作への追加の動作または代わりの動作を行ってもよい。]
[0064] （例えばブロック７２０でハンドオーバリクエストメッセージを受信することに応じて）ハンドオーバリクエストが引き受けられないと目標ｅＮＢ１２２−２が判断する場合、目標ｅＮＢ１２２−２は、ハンドオーバ準備失敗メッセージをソースｅＮＢ１２２−１へ送信してもよい。ハンドオーバ準備失敗メッセージは、生成されたハンドオーバフィードバック情報を含んでもよい。一実施形態では、ハンドオーバ準備失敗メッセージは、ＨＯ Ｅｖａｌｕａｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ ＤａｔａＩＥを含む、ＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮＦＡＩＬＵＲＥメッセージとして作成されてもよい。（ＨＯ Ｅｖａｌｕａｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ Ｄａｔａ ＩＥを含む）修正されたＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮ ＦＡＩＬＵＲＥメッセージの例示的な形式を、以下の表４に示す。]
[0065] ]
[0066] 図８Ａ乃至１１Ｃは、図７に関して上述した処理の例である。下記の例ではそれぞれ、ＵＥ１１０が現在ソースｅＮＢ１２２−１によってサポートされており、かつ、ソースｅＮＢ１２２−１はＵＥ１１０についてのハンドオーバが開始されることになると判断すると想定する。] 図７ 図８Ａ
[0067] 図８Ａに示す第１の例８００では、ソースｅＮＢ１２２−１が、見込まれる目標ｅＮＢにハンドオーバリクエスト８０５を送信してもよい。ソースｅＮＢ１２２−１が、見込まれる目標ｅＮＢ（例８００では目標ｅＮＢ１２２−２および目標ｅＮＢ１２２−３と表示される）にハンドオーバリクエスト８０５を送信してもよい。ハンドオーバリクエスト８０５は、ＲＲＭ情報（例えば上記のＵＥ固有のＲＲＭ情報および無線ベアラ固有ＲＲＭ情報）を含んでもよい。目標ｅＮＢ１２２−２および１２２−３は、ハンドオーバリクエスト８０５を受信し、そして、ハンドオーバリクエスト８０５に含まれたＲＲＭ情報に基づいて、ハンドオーバフィードバック情報を生成してもよい。例８００では、目標ｅＮＢ１２２−２へのハンドオーバが行われたならば恐らくＵＥ１１０の性能が劣化するリスクが大きいだろうということを示すハンドオーバフィードバック情報を生成すると想定する。また、目標ｅＮＢ１２２−３は、目標ｅＮＢ１２２−３へのハンドオーバが行われたならば恐らくＵＥ１１０の性能が劣化するリスクが小さいだろうということを示すハンドオーバフィードバック情報を生成すると想定する。目標ｅＮＢ１２２−２は、図８Ｂに示すように、自分のフィードバック情報を含むハンドオーバレスポンス８１０をソースｅＮＢ１２２−１に送信してもよい。また、目標ｅＮＢ１２２−３も、自分のフィードバック情報を含むハンドオーバレスポンス８１５をソースｅＮＢ１２２−１に送信してもよい。ハンドオーバレスポンス８１０および８１５を受信するのに応じて、ソースｅＮＢ１２２−１が、目標ｅＮＢ１２２−２と目標ｅＮＢ１２２−３との両方へのハンドオーバが可能であるけれども、ＵＥ１１０のユーザによって経験される性能の劣化が恐らく少ないであろうから、目標ｅＮＢ１２２−３の方が優先するであろうと判断してもよい。従って、図８Ｃに示すように、ソースｅＮＢ１２２−１が、ＵＥに目標ｅＮＢ１２２−３との通信８２５を開始させるために、ハンドオーバコマンド８２０をＵＥ１１０に送信してもよい。] 図８Ａ 図８Ｂ 図８Ｃ
[0068] 図９Ａに示す第２の例９００では、ソースｅＮＢ１２２−１が、ハンドオーバリクエスト９０５を目標ｅＮＢ１２２−２に送信してもよい。ハンドオーバリクエスト９０５は、ＲＲＭ情報（例えば上記のＵＥ固有ＲＲＭ情報および無線ベアラ固有ＲＲＭ情報）を含んでもよい。目標ｅＮＢ１２２−２は、ハンドオーバリクエスト９０５を受信し、そして、ハンドオーバリクエスト９０５に含まれたＲＲＭ情報に基づいて、ハンドオーバフィードバック情報を生成してもよい。例９００では、目標ｅＮＢ１２２−２へのハンドオーバが行われたならば恐らくＵＥ１１０の性能が劣化するリスクが大きいだろうということを示すハンドオーバフィードバック情報を生成すると想定する。目標ｅＮＢ１２２−２は、フィードバック情報を含むハンドオーバレスポンス９１０をソースｅＮＢ１２２−１に送信してもよい。ハンドオーバレスポンス９１０を受信するのに応じて、ソースｅＮＢ１２２−１は、ＵＥ１１０がソースｅＮＢ１２２−１と通信するためのスケジューリングストラテジーを修正してもよい。修正されたスケジューリングストラテジーは、ＵＥ１１０が目標ｅＮＢ１２２−２で受けるであろう通信性能にＵＥ１１０を適合させるための、ソースｅＮＢ１２２−１による試みであってもよい。ＵＥ１１０は、修正されたスケジューリングストラテジーに従ってソースｅＮＢ１２２−１と通信してもよい９１５。ソースｅＮＢ１２２−１は、図９Ｃに示すように、（例えば修正されたスケジューリングストラテジーを用いて）ＵＥに目標ｅＮＢ１２２−２との通信を９２５開始させるためにハンドオーバコマンド９２０をＵＥ１１０に送信してもよい（図９Ｂ）。] 図９Ａ 図９Ｂ 図９Ｃ
[0069] 図１０Ａに示す第３の例１０００では、ソースｅＮＢ１２２−１が、ハンドオーバリクエスト１００５を目標ｅＮＢ１２２−２へ送信してもよい。ハンドオーバリクエスト１００５は、ＲＲＭ情報（例えば上記のＵＥ固有ＲＲＭ情報および無線ベアラ固有ＲＲＭ情報）を含んでもよい。目標ｅＮＢ１２２−２は、ハンドオーバリクエスト１００５を受信し、そして、ハンドオーバリクエスト１００５に含まれたＲＲＭ情報に基づいて、ハンドオーバフィードバック情報を生成してもよい。例１０００では、目標ｅＮＢ１２２−２へのハンドオーバが行われたならば恐らくＵＥ１１０の性能が劣化するリスクが大きいだろうということを示すハンドオーバフィードバック情報を目標ｅＮＢ１２２−２が生成すると想定する。目標ｅＮＢ１２２−２は、フィードバック情報を含むハンドオーバレスポンス１０１０をソースｅＮＢ１２２−１へ送信してもよい。ハンドオーバレスポンス１０１０を受信するのに応じて、ソースｅＮＢ１２２−１は、１つ以上の進行中のサービスをＵＥ１１０に再構成させるためのコマンドを含むハンドオーバコマンド１０１５をＵＥ１１０へ送信してもよい。例えば、ソースｅＮＢ１２２−１が、例えばアプリケーションによるリソースの消費を減少させるために、ＵＥ１１０で現在実行中の１つ以上のアプリケーションの設定を、ＵＥ１１０に変更させてもよい。代案として、ハンドオーバコマンドは、ＵＥ１１０に１つ以上の進行中のサービスを再構成させるためのコマンドとは別であってもよい。コマンド１０１５に応じて、ＵＥ１１０が、１つ以上の進行中のサービスを再構成して、図１０Ｂに示すように（例えば再構成された進行中のサービスを用いて）目標ｅＮＢ１２２−２との通信１０２０を開始してもよい。] 図１０Ａ 図１０Ｂ
[0070] 図１１Ａに示す第４の例１１００では、ソースｅＮＢ１２２−１が、ハンドオーバリクエスト１１０５を目標ｅＮＢ１２２−２へ送信してもよい。ハンドオーバリクエスト１１０５は、ＲＲＭ情報（例えば上記のＵＥ固有ＲＲＭ情報および無線ベアラ固有ＲＲＭ情報）を含んでもよい。目標ｅＮＢ１２２−２は、ハンドオーバリクエスト１１０５を受信し、そして、ハンドオーバリクエスト１１０５に含まれたＲＲＭ情報に基づいて、ハンドオーバフィードバック情報を生成してもよい。例１１００では、目標ｅＮＢ１２２−２へのハンドオーバが行われたならば恐らくＵＥ１１０の性能が劣化するリスクが大きいだろうということを示すハンドオーバフィードバック情報を目標ｅＮＢ１２２−２が生成すると想定する。目標ｅＮＢ１２２−２は、フィードバック情報を含むハンドオーバレスポンス１１１０をソースｅＮＢ１２２−１へ送信してもよい。ハンドオーバレスポンス１１１０を受信するのに応じて、ソースｅＮＢ１２２−１は、劣化警告およびハンドオーバコマンド１１１５をＵＥ１１０へ送信してもよい。代案として、ハンドオーバコマンドは、劣化警告とは別であってもよい。劣化警告は、図１１Ｂに示すように、メッセージ１１２０をＵＥ１１０に関連するユーザに表示させてもよい。メッセージ１１２０は、性能の劣化の可能性が高いことを示してもよく、そして、例えば、性能の劣化の可能性を低下させるためにユーザが行いうる１つ以上の動作を示してもよい。ハンドオーバコマンドに応じてＵＥ１１０は、図１１Ｃに示すように（例えば、ユーザが１つ以上の動作を行う前または後に）、目標ｅＮＢ１２２−２との通信１１２５を開始してもよい。] 図１１Ａ 図１１Ｂ 図１１Ｃ
[0071] 理解されるであろうが、上記の技術は、他のハンドオーバシナリオにも同様に適用できる。例えば、図１２は、ハンドオーバを行うための別の例示的なプロセスのフローチャートである。一実施形態では、図１２に記述する処理が、ＭＭＥ／ＧＷ１３２−１およびｅＮＢ１２２−２（例えば目標ｅＮＢとして）によって行われてもよい。別の実施形態では、以下に記述する例示的なプロセスの一部または全部が、ＭＭＥ／ＧＷ１３２−１およびｅＮＢ１２２−２を含むかまたは除く、別のデバイスまたは複数のデバイスの組み合わせによって行われてもよい。] 図１２
[0072] 例示的なプロセスは、ＭＭＥ／ＧＷ１３２−１が、ソースｅＮＢ（ソースｅＮＢ１２２−１であると想定される）からＵＥ（ＵＥ１１０と想定される）についてのハンドオーバリクエストメッセージを受信することで始まってもよい（ブロック１２０５）。一実施形態では、ハンドオーバリクエストメッセージは、ＲＲＭ情報（例えばＵＥ固有ＲＲＭ情報および無線ベアラ固有ＲＲＭ情報）を含んでもよい。ハンドオーバリクエストメッセージは、例えば、３ＧＰＰ ＴＳ３６．４１３に定義されたＨＡＮＤＯＶＥＲ ＲＥＱＵＩＲＥＤメッセージを含んでもよい。ＭＭＥ／ＧＷ１３２−１は、ＳＩインタフェースでハンドオーバリクエストメッセージを受信してもよい。]
[0073] ＭＭＥ／ＧＷ１３２−１は、ＲＲＭ情報を含むハンドオーバリクエストメッセージを、目標ｅＮＢ１２２−２へ送信してもよい（ブロック１２１０）。一実施形態では、ハンドオーバリクエストメッセージは、３ＧＰＰ ＴＳ３６．４１３に定義されたＨＡＮＤＯＶＥＲＲＥＱＵＥＳＴメッセージを含んでもよい。ＭＭＥ／ＧＷ１３２−１は、ハンドオーバリクエストメッセージをＳ１インタフェースで転送してもよい。]
[0074] 目標ｅＮＢ１２２−２は、ハンドオーバリクエストメッセージを受信してもよく（ブロック１２１５）、そして、それに応じて、目標ｅＮＢ１２２−２についての現在のネットワーク情報を識別してもよい（ブロック１２２０）。一実施形態では、現在のネットワーク情報は、目標ｅＮＢ１２２−２の現在のリソース状況、例えば目標ｅＮＢ１２２−２の現在の容量状況および／または現在の負荷状況に関する情報を含んでもよい。]
[0075] 目標ｅＮＢ１２２−２は、ハンドオーバリクエストの中で受信されたＲＲＭ情報に基づいて、かつ、目標ｅＮＢ１２２−２についての識別された現在のネットワーク情報に基づいて、ＵＥ１１０についてのハンドオーバフィードバック情報を生成してもよい（ブロック１２２５）。ハンドオーバフィードバック情報は、例えば、受信されたＲＲＭ情報と目標ｅＮＢ１２２−２についての識別された現在のネットワーク情報とに基づいて、目標ｅＮＢ１２２−２がソースｅＮＢ１２２−１と同じアクティビティレベルをＵＥ１１０についてサポートできないことがあるという指標を含んでもよい。一実施形態では、指標は、劣化レベルとして提供されてもよい。例えば、「１」は、性能の劣化のリスクが小さいことを示してもよく、「２」は、性能の劣化のリスクが中程度であることを示してもよく、「３」は、性能の劣化のリスクが大きいことを示してもよく、その場合、ソースｅＮＢ１２２−１は、できればＵＥ１１０のアクティビティレベルを修正するように強く忠告される。加えて、ハンドオーバフィードバック情報は、ソースｅＮＢ１２２−１によって提供されるものより少ない無線リソースを受信してもよい無線ベアラを識別してもよい。また、ハンドオーバフィードバック情報は、目標ｅＮＢ１２２−２が（例えば、サポートされるパケット遅延、スループット等に関して）サポートしうるアクティビティを示してもよい。]
[0076] 目標ｅＮＢ１２２−２が、ハンドオーバレスポンスメッセージを作成してもよい（ブロック１２３０）。ハンドオーバレスポンスメッセージは、ハンドオーバフィードバック情報を含んでもよい。一実施形態では、ハンドオーバレスポンスメッセージは、３ＧＰＰ ＴＳ３６．４１３に定義されたＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴＡＣＫＮＯＷＬＥＤＧＥ（ハンドオーバリクエスト肯定応答）メッセージとして作成されてもよい。ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージの形式は、目標ｅＮＢ１２２−２によって生成されたハンドオーバフィードバック情報を含むように、上述したやり方と同様のやり方で修正されてもよい。]
[0077] 目標ｅＮＢ１２２−２は、ハンドオーバレスポンスメッセージをＭＭＥ／ＧＷ１３２−１へ転送してもよい（ブロック１２３０）。目標ｅＮＢ１２２−２は、ハンドオーバレスポンスメッセージをＳ１インタフェースで転送してもよい。]
[0078] ＭＭＥ／ＧＷ１３２−１が、ハンドオーバレスポンスメッセージを受信してもよい（ブロック１２３５）。それに応じて、ＭＭＥ／ＧＷ１３２−１は、ハンドオーバレスポンスメッセージの内容に基づいてハンドオーバコマンドを作成してもよい（ブロック１２４０）。一実施形態では、ハンドオーバコマンドが、３ＧＰＰ ＴＳ３６．４１３に定義されたＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤメッセージとして作成されてもよい。ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤメッセージの形式は、目標ｅＮＢ１２２−２によって生成されたハンドオーバフィードバック情報を含むように、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴＡＣＫＮＯＷＬＥＤＧＥメッセージに関して上述したやり方と同様のやり方で修正されてもよい。ＭＭＥ／ＧＷ１３２−１は、ハンドオーバコマンドをソースｅＮＢ１２２−１へ送信してもよい（ブロック１２４０）。ＭＭＥ／ＧＷ１３２−１からハンドオーバコマンドを受信した時点で、ソースｅＮＢ１２２−１は、図７に関して上述した１つ以上の動作を行ってもよい。] 図７
[0079] 本書で記述する実施形態には、ハンドオーバの後でＵＥがソースノードで現在受けているのと同じサービス品質をＵＥが目標ノードで受ける可能性を予測するシステムおよび／または方法が含まれてもよい。ソースノードは、関連する無線ベアラパラメータよりもきめ細かい情報を提供する、個別のＵＥについての（ＵＥ固有ＲＲＭ情報と呼ばれる）現在のアクティビティおよびリソース利用の情報を収集してもよい。この利点は、最大（またはピーク）ビットレートがＧＢＲよりも大きい（ＭＢＲ＞ＧＢＲ）非ＧＢＲベアラとＧＢＲベアラとの両方に適用可能であってもよい。結果として、目標ノードは、無線ベアラ固有のＲＲＭ情報だけから目標ノードが得ることができる情報よりも、ＵＥの実際のリソース要件に関するもっと正確な情報ともっときめ細かい情報とを有することができる。目標ノードは、この情報を用いて、ハンドオーバの後で新たなセル（すなわち、目標ノードによって提供されるセル）で同じＱｏＳをＵＥが受ける可能性を示す予測をソースノードに提供することができる。また、目標ノードは、ハンドオーバの準備が失敗した場合に備えて、ハンドオーバフィードバック情報を提供してもよい。従って、ソースノードのハンドオーバの決定が、ハンドオーバの時点でもう使われていない可能性があった背景負荷情報によってだけでなく、目標ノードのリソース状況についての最新情報によっても助けられてよい。]
[0080] 一実施形態では、ソースノードは、ベストエフォート（非ＧＢＲ）のアプリケーションまたは弾力的な（ＭＢＲ＞ＧＢＲ）アプリケーションを実行しているＵＥに積極的に警告を送信することができる。警告は、目標ノードは最小ビットレートおよびＱｏＳに責任を持つことはできるが、知覚されるＱｏＳの劣化がハンドオーバの実行後に発生しそうであることを示してもよい。例えば、ＵＥは、アプリケーションレイヤに対するレイヤ間信号の中でこの情報を用いることもできる。結果として、ＵＥは、ハンドオーバの前の所定の時期に再構成すること（そして、新たなリソース状況に適合すること）によって、リソースの問題を持つセルの中でサービスを受け続ける可能性が高まってもよい。]
[0081] 本書で記述した実施形態は、図解と記述とを提供するが、網羅的であることや、開示されたまさにその形態に実装を限定することは意図されていない。修正形態や変形形態が、上記の教示内容に照らして実行できるし、あるいは、実施形態の実践から得られることもある。例えば、上記の技術は、ハンドオーバの実行の間に目標ノードからソースノードにハンドオーバフィードバック情報を提供することに関するものだが、他の実施形態では、ハンドオーバフィードバック情報が、（例えば再交渉プロセスの一部として）他の時間帯に提供されてもよい。]
[0082] 図７および１２に関して一連のブロックを記述してきたが、ブロックの順序が、他の実施形態で修正されてもよい。また、非依存のブロックは、並行して行われてもよい。] 図７
[0083] 上記の例示的な実施形態は、図に示した実施形態において多くの異なる形のソフトウェア、ファームウェア、およびハードウェアとして実装されてもよい。本書で記述した例示的な実施形態を実装するのに用いられる実際のソフトウェアコードまたは特別な制御ハードウェアは、本発明を限定するものではない。従って、例示的な実施形態の操作および振る舞いは、特定のソフトウェアコードに関係なく記述されたものであり、本書の記述に基づいて例示的な実施形態を実装するためにソフトウェアおよび制御ハードウェアを設計することは可能であろうということが理解される。]
[0084] さらに、本発明の一定の部分が、１つ以上の機能を実行する「ロジック」として実装されてもよい。このロジックは、例えば特定用途向け集積回路、フィールド・プログラマブル・ゲート・アレイ、プロセッサまたはマイクロプロセッサのようなハードウェア、あるいはハードウェアとソフトウェアとの組み合わせとを含んでもよい。]
[0085] 諸機能の特定の組み合わせが、請求項で列挙されたり、および／または明細書で開示されたりしているけれども、これらの組み合わせは、本発明を限定することを意図していない。実際、これらの諸機能の多くは、具体的に請求項で列挙されたり、および／または明細書で開示されたりしていないやり方で組み合わせられてもよい。]
[0086] 強調されるべきだが、この明細書で用いられる場合の「備える／備えている（ｃｏｍｐｒｉｓｅｓ／ｃｏｍｐｒｉｓｉｎｇ）」という用語は、述べられた機能、整数、ステップまたはコンポーネントの存在を明記すると考えられるが、１つ以上の他の機能、整数、ステップ、コンポーネントの存在または追加を除外していない。]
[0087] 本願の記述で用いられる要素、動作、または命令はいずれも、そのように明示的に記述されない限り、本発明にとって重要不可欠とか必須であると解釈されてはならない。]
[0088] また、本書では、冠詞「ａ」は、１つ以上の項目を含むことが意図される。１つの項目だけが意図される場合、「１つの」という用語または同様の言葉が用いられる。さらに、「に基づいて」という句は、他に明示的に述べない限り、「に、少なくとも部分的に、基づいて」を意味することが意図される。]

权利要求:

請求項1
ユーザ装置にサービスを提供するソースノードとターゲットノードとを備えるシステムにおいて実行される方法であって、無線リソース管理情報を保持するステップと、ハードオーバを開始すると決定するステップと、前記無線リソース管理情報を含むハンドオーバリクエストメッセージを前記ターゲットノードへ送信するステップと、前記ターゲットノードにおいて前記ハンドオーバリクエストメッセージを受信すると、前記ターゲットノードについての現在のネットワーク情報を特定するステップと、前記ターゲットノードについて特定された前記現在のネットワーク情報と、前記無線リソース管理情報とに基づいて前記ユーザ装置についてのハンドオーバフィードバック情報を生成するステップと、前記生成されたハンドオーバフィードバック情報を含むハンドオーバレスポンスメッセージを前記ソースノードへ送信するステップと、前記ソースノードにおいて前記ハンドオーバレスポンスメッセージを受信すると、前記生成されたハンドオーバフィードバック情報に基づいてハンドオーバ関連アクションを実行するステップとを有することを特徴とする方法。
請求項2
前記無線リソース管理情報には、ユーザ装置の固有の情報、または無線ベアラの固有の情報の１つ以上が含まれていることを特徴とする請求項１に記載の方法。
請求項3
前記ユーザ装置の固有の情報には、前記ユーザ装置の現在におけるアクティビティレベルに関する情報と、前記ユーザ装置が使用している無線リソースに関する情報と、前記ユーザ装置のサービス品質に関する情報とのうち少なくとも１つが含まれていることを特徴とする請求項２に記載の方法。
請求項4
前記無線ベアラの固有の情報には、無線ベアラの現在におけるアクティビティレベルに関する情報と、無線ベアラが使用している無線リソースに関する情報と、前記無線ベアラによって提供されているサービス品質に関する情報とのうち少なくとも１つが含まれていることを特徴とする請求項２に記載の方法。
請求項5
前記ソースノードは、ビットレートが保証されていない無線ベアラと、ビットレートが保証された無線ベアラであって、該無線ベアラについての最大ビットレートがビットレート保証値よりも大きい、該無線ベアラとのうち少なくとも１つを介して前記ユーザ装置へサービスを提供し、前記無線リソース管理情報を保持するステップは、前記ビットレートが保証されていない無線ベアラと、前記ビットレートが保証された無線ベアラとの少なくとも１つに関連した無線リソース管理情報を保持するステップを含むことを特徴とする請求項１に記載の方法。
請求項6
前記システムは、モビリティ管理エンティティをさらに備え、前記ハンドオーバリクエストメッセージを送信するステップと、前記ハンドオーバレスポンスメッセージを送信するステップとが、Ｓ１インタフェースを介して、前記モビリティ管理エンティティによって実行されることを特徴とする請求項１に記載の方法。
請求項7
前記ハンドオーバレスポンスメッセージは、第１の情報要素を有したハンドオーバリクエスト肯定応答メッセージと、第２の情報要素を有したハンドオーバ準備失敗メッセージとのうちいずれか一方を有し、前記第１の情報要素および前記第２の情報要素には、前記生成されたハンドオーバフィードバック情報が含まれていることを特徴とする請求項１に記載の方法。
請求項8
前記ハンドオーバレスポンスメッセージには、ハンドオーバ先の進化型ノードＢからハンドオーバ元の進化型ノードＢへのトランスペアレントコンテナが含まれており、前記ハンドオーバ先の進化型ノードＢからハンドオーバ元の進化型ノードＢへのトランスペアレントコンテナには、前記生成されたハンドオーバフィードバック情報が含まれていることを特徴とする請求項１に記載の方法。
請求項9
前記生成されたハンドオーバフィードバック情報には、前記ユーザ装置についての前記ソースノードが提供しているアクティビティレベルと同等のアクティビティレベルを前記ターゲットノードがサポートしていないことを示すインジケーションと、前記ソースノードによって提供されている無線リソースよりも少ない無線リソースしか特定の無線ベアラが受信できないことを示すインジケーションと、前記ターゲットノードがサポートできるアクティビティレベルを示すインジケーションとのうち少なくとも１つが含まれていることを特徴とする請求項１に記載の方法。
請求項10
前記ハンドオーバ関連アクションを実行するステップは、他のターゲットノードとの通信を前記ユーザ装置に開始させる第１コマンドを送信するステップと、前記ユーザ装置によって使用されているスケジューリングストラテジーを修正して、前記ターゲットノードによって使用されているスケジューリングストラテジーに整合させるステップと、継続中のサービスを前記ユーザ装置に再構成させる第２コマンドを送信するステップと、前記ターゲットノードへとハンドオーバするとサービスが低下することを警告するための第３コマンドを送信するステップとのうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
請求項11
ソースノードとターゲットノードとを備えるシステムであって、前記ソースノードは、無線リソース管理情報を収集し、ユーザ装置についてハードオーバを開始すると決定し、前記ユーザ装置についてハードオーバを開始すると決定すると、前記無線リソース管理情報を含むハンドオーバリクエストメッセージを送信し、前記ターゲットノードは、前記ソースノードから前記ハンドオーバリクエストメッセージを受信し、前記ハンドオーバリクエストメッセージを受信したことに応じて、前記ターゲットノードについての現在のネットワーク情報を特定し、前記特定された現在のネットワーク情報と、前記無線リソース管理情報とに基づいて前記ユーザ装置についてのハンドオーバフィードバック情報を生成し、前記ソースノードがハンドオーバに関連した決定を行うことを支援する前記ハンドオーバフィードバック情報を含むハンドオーバレスポンスメッセージを前記ソースノードへ送信することを特徴とするシステム。
請求項12
前記無線リソース管理情報には、ユーザ装置の固有の情報、または無線ベアラの固有の情報の１つ以上が含まれていることを特徴とする請求項１１に記載のシステム。
請求項13
前記ユーザ装置の固有の情報には、前記ユーザ装置の現在におけるアクティビティレベルに関する情報と、前記ユーザ装置が使用している無線リソースに関する情報と、前記ユーザ装置のサービス品質に関する情報とのうち少なくとも１つが含まれていることを特徴とする請求項１２に記載のシステム。
請求項14
前記無線ベアラの固有の情報には、無線ベアラの現在におけるアクティビティレベルに関する情報と、無線ベアラが使用している無線リソースに関する情報と、前記無線ベアラによって提供されているサービス品質に関する情報とのうち少なくとも１つが含まれていることを特徴とする請求項１２に記載のシステム。
請求項15
前記ソースノードは、ビットレートが保証されていない無線ベアラと、ビットレートが保証された無線ベアラであって、該無線ベアラについての最大ビットレートがビットレート保証値よりも大きい、該無線ベアラとのうち少なくとも１つを介して前記ユーザ装置へサービスを提供することを特徴とする請求項１１に記載のシステム。
請求項16
前記ソースノードは、Ｘ２インタフェースを介して前記ハンドオーバリクエストメッセージを送信し、前記ターゲットノードは、Ｘ２インタフェースを介して前記ハンドオーバレスポンスメッセージを送信することを特徴とする請求項１１に記載のシステム。
請求項17
前記ハンドオーバレスポンスメッセージは、第１の情報要素を有したハンドオーバリクエスト肯定応答メッセージと、第２の情報要素を有したハンドオーバ準備失敗メッセージとのうちいずれか一方を有し、前記第１の情報要素および前記第２の情報要素には、前記生成されたハンドオーバフィードバック情報が含まれていることを特徴とする請求項１１に記載のシステム。
請求項18
前記ハンドオーバレスポンスメッセージには、ハンドオーバ先の進化型ノードＢからハンドオーバ元の進化型ノードＢへのトランスペアレントコンテナが含まれており、前記ハンドオーバ先の進化型ノードＢからハンドオーバ元の進化型ノードＢへのトランスペアレントコンテナには、前記生成されたハンドオーバフィードバック情報が含まれていることを特徴とする請求項１１に記載のシステム。
請求項19
前記生成されたハンドオーバフィードバック情報には、前記ユーザ装置についての前記ソースノードが提供しているアクティビティレベルと同等のアクティビティレベルを前記ターゲットノードがサポートしていないことを示すインジケーションと、前記ソースノードによって提供されている無線リソースよりも少ない無線リソースしか特定の無線ベアラが受信できないことを示すインジケーションと、前記ターゲットノードがサポートできるアクティビティレベルを示すインジケーションとのうち少なくとも１つが含まれていることを特徴とする請求項１１に記載のシステム。
請求項20
前記ソースノードは、他のターゲットノードとの通信を前記ユーザ装置に開始させる第１コマンドを送信するステップと、前記ユーザ装置によって使用されているスケジューリングストラテジーを修正して、前記ターゲットノードによって使用されているスケジューリングストラテジーに整合させるステップと、継続中のサービスを前記ユーザ装置に再構成させる第２コマンドを送信するステップと、前記ターゲットノードへとハンドオーバするとサービスが低下することを警告するための第３コマンドを送信するステップとのうち少なくとも１つのステップを実行することを特徴とする請求項１１に記載のシステム。
請求項21
ネットワークにおいてハンドオーバ元となる進化型ノードＢであって、前記進化型ノードＢと連携している少なくとも１つのユーザ装置についての無線リソース管理情報または前記ユーザ装置と関連付けられている無線ベアラについての無線リソース管理情報を記憶する記憶装置と、処理ロジック部とを備え、前記処理ロジック部は、前記ユーザ装置についてハードオーバを開始すると決定し、前記ハードオーバを開始すると決定すると前記無線リソース管理情報を含むハンドオーバリクエストメッセージを生成し、Ｘ２インタフェースを介して前記ハンドオーバリクエストメッセージを、ハンドオーバ先となる進化型ノードＢへ送信し、前記ハンドオーバリクエストメッセージを前記ハンドオーバ先となる進化型ノードＢへ送信したことに応じて、前記ハンドオーバ元となる進化型ノードＢがハンドオーバに関連した決定を行うことを支援する前記無線リソース管理情報を含む、ハンドオーバリクエスト肯定応答メッセージと、ハンドオーバ準備失敗メッセージとのいずれか一方を、前記Ｘ２インタフェースを介して受信し、前記ハンドオーバリクエスト肯定応答メッセージと、ハンドオーバ準備失敗メッセージとのいずれか一方に含まれていた前記無線リソース管理情報に基づいてハンドオーバに関連した決定を実行することを特徴とする進化型ノードＢ。
請求項22
前記無線リソース管理情報には、前記ハンドオーバリクエスト肯定応答メッセージと、ハンドオーバ準備失敗メッセージとのいずれか一方の情報要素が含まれていることを特徴とする請求項２１に記載の進化型ノードＢ。
請求項23
前記ハンドオーバ元となる進化型ノードＢは、前記ハンドオーバリクエスト肯定応答メッセージを受信し、前記ハンドオーバリクエスト肯定応答メッセージに含まれている、ハンドオーバ先となる進化型ノードＢからハンドオーバ元となる進化型ノードＢへのトランスペアレントコンテナに、前記無線リソース管理情報が含まれていることを特徴とする請求項２１に記載の進化型ノードＢ。
請求項24
前記処理ロジック部は、前記ハードオーバに関連した決定を実行する際に、他のターゲットノードとの通信を前記ユーザ装置に開始させる第１コマンドを送信するステップと、前記ユーザ装置によって使用されているスケジューリングストラテジーを修正して、前記ターゲットノードによって使用されているスケジューリングストラテジーに整合させるステップと、継続中のサービスを前記ユーザ装置に再構成させる第２コマンドを送信するステップと、前記ターゲットノードへとハンドオーバするとサービスが低下することを警告するための第３コマンドを送信するステップとのうち少なくとも１つを実行することを特徴とする請求項２１に記載の進化型ノードＢ。
請求項25
ネットワークにおいてハンドオーバ先となる進化型ノードＢであって、指示を記憶する記憶装置と、前記指示を実行する処理ロジック部とを備え、前記処理ロジック部は、ユーザ装置に関連した無線リソース管理情報を含むハンドオーバリクエストメッセージを、ハンドオーバ元となる進化型ノードＢから受信し、前記ハンドオーバリクエストメッセージを受信すると、前記ハンドオーバ先となる進化型ノードＢにおける現在のリソース使用状況を特定し、前記特定されたリソース使用状況と、前記無線リソース管理情報とに基づいて、ハンドオーバフィードバック情報を生成し、前記ハンドオーバ元となる進化型ノードＢがハンドオーバに関連した決定を実行することを支援する前記ハンドオーバフィードバック情報を含む、ハンドオーバリクエスト肯定応答メッセージと、ハンドオーバ準備失敗メッセージとのいずれか一方を前記ハンドオーバ元となる進化型ノードＢに送信することを特徴とする進化型ノードＢ。
請求項26
前記生成されたハンドオーバフィードバック情報には、前記ユーザ装置についての前記ハンドオーバ元となる進化型ノードＢが提供しているアクティビティレベルと同等のアクティビティレベルを前記ハンドオーバ先となる進化型ノードＢがサポートしていないことを示すインジケーションと、前記ハンドオーバ元となる進化型ノードＢによって提供されている無線リソースよりも少ない無線リソースしか特定の無線ベアラが受信できないことを示すインジケーションと、前記ハンドオーバ先となる進化型ノードＢがサポートできるアクティビティレベルを示すインジケーションとのうち少なくとも１つが含まれていることを特徴とする請求項２５に記載の進化型ノードＢ。
請求項27
前記ハンドオーバ先となる進化型ノードＢは、前記生成されたハンドオーバフィードバック情報を、ハンドオーバリクエスト肯定応答メッセージと、ハンドオーバ準備失敗メッセージとのうちいずれか一方の情報要素、または、前記ハンドオーバリクエスト肯定応答メッセージに含まれる、前記ハンドオーバ先となる進化型ノードＢから前記ハンドオーバ元となる進化型ノードＢへのトランスペアレントコンテナに搭載することを特徴とする請求項２５に記載の進化型ノードＢ。
請求項28
ソースノードとターゲットノードとを備えたネットワークにおける管理エンティティ装置であって、指示を記憶する記憶装置と、前記指示を実行する処理ロジック部とを備え前記処理ロジック部は、前記ターゲットノードに対するハンドオーバを考慮しているユーザ装置に関連した無線リソース管理情報を含むハンドオーバリクエストメッセージを前記ターゲットノードへ送信し、前記ハンドオーバリクエストメッセージを前記ターゲットノードへ送信したことに応じて、前記ソースノードが前記ユーザ装置に提供しているサービス品質と同等のサービス品質を前記ターゲットノードが提供する尤度を示す予測情報を含んだハンドオーバレスポンスメッセージを前記ターゲットノードから受信し、前記予測情報を含んだハンドオーバコマンドを前記ソースノードへ供給することを特徴とする管理エンティティ装置。
請求項29
前記予測情報には、前記ユーザ装置についての前記ソースノードが提供しているアクティビティレベルと同等のアクティビティレベルを前記ターゲットノードがサポートしていないことを示すインジケーションと、前記ソースノードによって提供されている無線リソースよりも少ない無線リソースしか特定の無線ベアラが受信できないことを示すインジケーションと、前記ターゲットノードがサポートできるアクティビティレベルを示すインジケーションとのうち少なくとも１つが含まれていることを特徴とする請求項２８に記載の管理エンティティ装置。
請求項30
ターゲットノードと、ベストエフォートタイプのアプリケーションと融通性のあるアプリケーションとの少なくとも一方を実行しているユーザ装置に対してサービスを提供しているソースノードとを備えたシステムにおいてハンドオーバをアシストする方法であって、前記ソースノードが実行するステップとして、無線リソース管理情報を保持するステップと、ハードオーバを開始すると決定するステップと、前記無線リソース管理情報を含むハンドオーバリクエストメッセージを前記ターゲットノードへ送信するステップと、前記ユーザ装置についてのハンドオーバフィードバック情報を含んだハンドオーバレスポンスメッセージを前記ターゲットノードから受信するステップと、前記ハンドオーバレスポンスメッセージを受信すると、前記ハンドオーバフィードバック情報に基づいて、ハンドオーバに関連したアクションを実行するステップとを有することを特徴とする方法。
請求項31
前記ハンドオーバフィードバック情報には、前記ユーザ装置についての前記ソースノードが提供しているアクティビティレベルと同等のアクティビティレベルを前記ターゲットノードがサポートしていないことを示すインジケーションと、前記ソースノードによって提供されている無線リソースよりも少ない無線リソースしか特定の無線ベアラが受信できないことを示すインジケーションと、前記ターゲットノードがサポートできるアクティビティレベルを示すインジケーションとのうち少なくとも１つが含まれていることを特徴とする請求項３０に記載の方法。
請求項32
前記ハンドオーバに関連したアクションを実行するステップは、他のターゲットノードとの通信を前記ユーザ装置に開始させる第１コマンドを送信するステップと、前記ユーザ装置によって使用されているスケジューリングストラテジーを修正して、前記ターゲットノードによって使用されているスケジューリングストラテジーに整合させるステップと、継続中のサービスを前記ユーザ装置に再構成させる第２コマンドを送信するステップと、前記ターゲットノードへとハンドオーバするとサービスが低下することを警告するための第３コマンドを送信するステップとのうち少なくとも１つを含むことを特徴とする請求項３０に記載の方法。
請求項33
ターゲットノードと、ベストエフォートタイプのアプリケーションと融通性のあるアプリケーションとの少なくとも一方を実行しているユーザ装置に対してサービスを提供しているソースノードとを備えたシステムにおいてハンドオーバをアシストする方法であって、前記ターゲットノードが実行するステップとして、無線リソース管理情報を含んだハンドオーバリクエストメッセージを前記ソースノードから受信するステップと、前記ハンドオーバリクエストメッセージを受信したことに応じて、前記ターゲットノードについての現在のネットワーク情報を特定するステップと、前記現在のネットワーク情報と、前記無線リソース管理情報とに基づいて前記ユーザ装置についてのハンドオーバフィードバック情報を生成するステップと、前記生成されたハンドオーバフィードバック情報を含むハンドオーバレスポンスメッセージを前記ソースノードへ送信するステップとを有することを特徴とする方法。
請求項34
前記無線リソース管理情報には、ユーザ装置の固有の情報、または無線ベアラの固有の情報の１つ以上が含まれていることを特徴とする請求項３３に記載の方法。
請求項35
前記ハンドオーバフィードバック情報には、前記ユーザ装置についての前記ソースノードが提供しているアクティビティレベルと同等のアクティビティレベルを前記ターゲットノードがサポートしていないことを示すインジケーションと、前記ソースノードによって提供されている無線リソースよりも少ない無線リソースしか特定の無線ベアラが受信できないことを示すインジケーションと、前記ターゲットノードがサポートできるアクティビティレベルを示すインジケーションとのうち少なくとも１つが含まれていることを特徴とする請求項３３に記載の方法。